Jeff Layman wrote:
> Other than what you and others have suggested, the problem is it's an
> unknown moving target.
Hi Jeff,
I want to learn whatever I can from people like you and Jeff Liebermann!
Yes. Indeed. You are completely correct. We can only protect against what
we already know to be a threat (usually based on a news article or two).
Hence I agree with your observation that it's not only a "moving" target,
it's a "growing" target, like snowball rolling down the hill on soft snow.
That's why, I think, we need each other. You know a lot. I know a lot.
Jeff Liebermann knows a lot.
Lot's of people know a lot more than any one of us.
> You noticed your unwanted Google account being created from using Gmail
> on the phone.
Yes Jeff. I noticed this _only_ accidentally, since all of a sudden I had a
Google Account on my phone. WTF? Where'd that come from, I thought. So I
deleted it. And then it came back. That's when I was able to reproduce why.
(Same with Google Voice, or logging into Google Maps, etc., as I recall).
Some privacy things we notice because they're overt, such as the SSID_nomap
privacy items, but some aren't obvious - such as the fact Wigle does NOT
respect the _nomap request (AFAIK).
Then you have to come up with things that are NOT obvious, which is why
a.i.w is involved in this thread, since your SOHO router comes into play
with mobile phone privacy. Allow me to outline, briefly, what that's so...
a. You know about butterfly hash tables so you set your SOHO SSID unique
b. In addition, you know about _nomap (& _optout_) for Google/Mozilla
c. And you know it's not only your SSID but your unique SSN & GPS location
d. Where SSN in here points out that the _AP MAC is unique_ to you alone
e. And no, as Jeff Liebermann knows, that AP MAC can not easily be spoofed
f. So you dutifully set the (already unique) SOHO SSID to append _nomap
g. You "think" that _nomaop prevents it being "uploaded" to Google/Mozilla
h. But (almost) every Android phone _still_ uploads your SSID to the net!
i. WTF? Then you realize, it's on the Google server the _nomap is respected
j. Worse, you find out that Wigle & NetStumbler maybe don't respect _nomap
k. Now what? You think. You ponder. You google. You search.
l. You come up with an idea after testing how Android handles hidden SSIDs
m. What if you make the SSID _hidden_ (i.e., not broadcast) you ponder?
n. You search a bit more and you find it that maybe that will work
o. If you don't broadcast the SSID, then it's NOT uploaded to the net!
p. At least not for most Android phones that don't have Wigle/Netstumbler
q. But a hidden SSID opens up another privacy can of worms, doesn't it.
r. Now you have to set your phone to _look_ for that hidden SSID
s. That means everywhere you go, your phone _broadcasts_ that hidden SSID
t. Yikes! So you set your phone to NOT re-connect after losing signal
u. While you're at it, you set Android 10+ to a random MAC per SSID
v. On Android 11+ Developer options, you set a random MAC per connection
w. So now, when the connection drops, it doesn't ask to reconnect at home
x. But the benefit is it doesn't broadcast your unique SSID outside home
y. You could have accomplished that task with an automated home geofence
z. But that would necessitate location - which is another can of worms!
Jeff... I ran out of letters, so I'll stop there... but it goes on,
which is your point and which is mine where, I can't help but logically
and rationally reasonably agree with you that it's hard to protect
against what we don't know about...
But at least we can protect against what we _do_ know about.
> More to the point is when it's not obvious what Google is
> doing in the background. And, to be fair, it's not only Google.
Oh indeed!
Take the case of turning on location (which comes after "z" above)!
How many people know that when Google Maps turns on "location" it uses its
own Google-specific activity which is different from the "normal" location.
Action = ACTION.MAIN (android.intent.action.MAIN)
Package Name = com.google.android.gms
Class Name = com.google.android.gms.location.settings.LocationAccuracyActivity
Category = CATEGORY.LAUNCHER (android.intent.category.LAUNCHER)
Every other method to turn on location does _not_ use that - they use this:
ACTION: "android.intent.action.MAIN"
PACKAGE: "com.android.settings"
CLASS: "com.android.settings.Settings$ScanningSettingsActivity"
They do different things!
Pop Quiz!
Guess which one turns on lots more privacy losing stuff, Jeff!
C'mon. Guess!
C:\> adb shell am start -n com.google.android.gms/.location.settings.LocationAccuracyActivity
> I have a
> Huawei phone which, like many manufacturers, runs a modified version of
> Android (particularly so with Chinese phones after their disagreement
> with Google). So what is /that/ version doing in the background? It
> might be different from what Google Android is doing. Let's not forget
> that the hardware is supplied by Huawei too; any "backdoors" in those
> chips? And then, of course, you have the cellphone signal provider.
> Everything goes through them, so if it's unencrypted...
Yup. We need debugging information.
We can use adb for "some" of that, but the problem I have with adb is that
I don't understand yet how best to cull the output into something usable.
C:\> adb shell am start -n com.google.android.gms/.gcm.GcmDiagnostics
(take a look at the
mtalk.google.com traffic, for example)
> As it's possible to have more than one Google account associated with a
> single cellphone, perhaps jumping between accounts when using the phone
> might cause some confusion at Google HQ (although I'm sure they can work
> their way round that).
Hmmmmm...... I never thought of having even one account, let alone multiple
accounts, but I prefer no account on the phone (or on the Windows PC).
What I'd love to know is what other privacy measures I can take on either.
Any suggestions?
--
Posted out of the goodness of my heart to disseminate useful information
which, in this case, is to logically agree with Jeff's comments and to
flesh out for the benefit of all what kinds of questions we need to ask.